nimblefandomcom-20200213-history
NIMBLE Wikia
The Nimble System is developed through the collaboration of experienced IT industry professionals. Nimble progresses beyond the concepts and demonstrates systems management document solutions to effectively manage your daily challenges and pain points. Overview The goal of the Nimble system is to provide a clear, simple method of communication that is easy to understand and ready for implementation into your organizations management process with little or no modification. References: www.nimblesystems.org The Nimble System The Nimble systems management document is intended to be a collaborative effort. The methods of communication and development are to use several collaborative tools. The Nimble systems management document will utilize three primary means of communication and collaboration, the Nimble wiki, blog and document repository. Wiki The NIMBLE wiki will provide an open collaboration community. The varied knowledge and experience of IT industry project management professionals and technology practitioners is vital to the development and continued improvement through the wiki publishing platform. Refreshing the content, structure and document organization will provide a document that is more readily assimilated into your organizations systems management practice. Blog The NIMBLE blog will create an open collaborative conversation for the further development and adaptation for and by users and collaborators. Allowing for an interactive experience for contributors to comment on collaborative content but also providing a professional context and practical examples & recommendations that aid practitioners in an effectively planning and executing IT operations. Document Repository The NIMBLE document repository will provide various versions and formats to support a wide array of users and collaborators needs. Ideally these products will be checked out, improved upon and checked in for review and final editing. The Nimble Document The Nimble integrated management bus provides a method of communication optimized for managing your digital IT systems. This system is compiled into an integrated system of documents. The Nimble systems management document is loosely coupled with accepted industry standards. The Nimble document system directly supports the System Development Life Cycle (SDLC), the Information Technology Infrastructure Library (ITIL), Enterprise Architecture (EA) and the Project Management Body of Knowledge (PMBOK). The document framework integrates seamlessly with these methodologies. Document Organization The Nimble document is a collection of mutually supporting documents integrated into a single document or system. The Nimble management document is structured upon four fundamental systems management processes that are used as the documentation framework: Design The design document includes the requirements gathering, design and the development of the deployment or project plan. # Technical Requirements: The technical requirements document will compile the results from gathering application and system requirements to determine that the network, CPU, memory and storage resources will meet the most demanding periods of utilization. Accurately identifying and documenting the technical requirements are critical to determining financial cost, compute cost and requirements traceability. # The Design Document: The design document will provide detailed technical guidance required by line of service personnel for configuring assets or obtaining technical resources & services. Deploy: The deployment document consists of the execution of the project plan developed in the planning phase. # Project Plan: The project plan document will communicate a deliberate plan of deploying resources, assets or services within the given time requirements to meet the specific technical, functional and business requirements identified in the technical requirements and design document. # Requirements Traceability: The technical requirements identified in the design phase must be satisfied or waived before the project can be considered completed and the system, application or component successfully implemented. # The Configuration Management Data Base (CMDB): The asset management inventory establishes a baseline for the configuration of the system components and applications. This is the corner stone of the systems management architecture. The initial system baseline inventory or record must be created or updated to reflect changes or additions in resources, services or assets deployed by the successful completion of the project plan. Maintain: The maintenance document is intended to enable the system to provide the service or resource in accordance with your organizations accepted standards for continuous operation. The maintenance documents will provide a system management framework that will enable line of service personnel to provide the system, application or component availability in accordance with your organizations accepted standards. # Systems Management: The systems maintenance document provides a policy that will be identified and defined to determine the organizational accepted standard of availability for systems, applications and components of the CMDB. The systems management document will define system monitoring standards and methods of communication and notification for incidents. # OS and Application Patching: The operating system and application patching document will provide a standard operating procedure for scheduling application maintenance and assessing impact of potential downtime and communicating planned outages or periods of limited availability. # Vulnerability Management: The vulnerability management document will define the method of determining the impact of known vulnerabilities on the managed system, application or component. Vulnerability management will include a process of remediation the threat or vulnerability such as applying or installing a patch update or fix. # Incident Management: Incidents are those events that negatively impact the performance or function of a system, application or component. The incident management document will be a system of record that will be instrumental in identifying, documenting and resolving incidents. The incident management document will define the following: * Policy on how to record and store data related to incident type, priority and severity details identifying the nature of the failure or reduction in performance. * Identify and record the affected system, application or component by administrative name or asset ID. * Record and store any error details or log entries of the affected hardware, software, firmware or application name and version. * Identify and record the time and date of the incident and the identity of the personnel reporting or identifying the incident. Sustain: The sustainment document is intended for the system application or supporting components to sustain operation as determined by initial business, functional or technical requirements. As technology and resource requirement change the system must adapt to meet these requirements. The sustainment document provides a process for the system, application or component to sustain operations as is defined by business, functional or technical requirements. As technology and resource requirements change, the system must adapt to meet the stated requirements. # Risk Management: The purpose of the risk management plan is to identify, manage and if possible mitigate risk across all levels of system operation and function. The risk assessment identifies known risks and assigns a value to determine the appropriate impact and compensating controls. Risk is managed or mitigated through implementing risk controls or accepting known risks. When risk is waived, known risks may accepted during a time period that risk controls may be in the implementation process and are not yet fully functional. Accepting known risks is done when the cost of implementing risk mitigating controls are greater than the risk itself. Compensating controls often can be implemented to reduce the assessed impact of an accepted risk. # Upgrades: Implementing improvements for new system, application, software, firmware and hardware enhancements and technical requirements is a planned and deliberate process. The upgrade plan identifies critical resources and services to be coordinated and managed similar to the deployment plan. < Time to get on board > ] Category:Browse